SNMP Perl Scripts

Posted on by Admin

Related Post

 

SNMP Perl Scripts

Occasionally I need to access a switch with goofed up AAA configuration or a bunch of switches that I want to execute the same commands on.  When I used to work for a big Fortune 500 company this became more of a necessity, so I wrote the following Perl script to copy and push configuration to the devices in question.  I found myself needing this script again as I prepared hundreds of routers and switches for addition to LMS (CiscoWorks). The only information you need is the read-write community string to copy or update the configuration.

Copying the Configuration

This script copies the switch’s running configuration to the TFTP server. The usage is perl TFTP_Copy.pl 192.168.1.1 Core-Config.txt, where 192.168.1.1 is the router/switch and Core-Config.txt is the filename for the config file copied to your TFTP server. Here is the code:

use strict;
use warnings;
use lib "C:/Perl/site/lib";
use Cisco::CopyConfig ();

# declare variables
my $ipAddress = $ARGV[0];
my $SNMPcommunity = ‘SyComCommunity’;
my $configFile = $ARGV[1];
my $TFTPServer = ‘192.168.52.5’;

# create a new Cisco::CopyConfig object
my $copyConfig = Cisco::CopyConfig->new(
Host => $ipAddress,
Comm => $SNMPcommunity,
);

# copy the running-configuration file to the TFTP server
print “Now copying the running-config on $ipAddress to the TFTP server… “;
if($copyConfig->copy($TFTPServer, $configFile)){
print “success.\n”;
}
else{
die $copyConfig->error();
}

# free up memory
$copyConfig = undef;

Once you open the copied configuration file, it will be an exact copy of the running configuration. This is useful for making backups of your device configurations or for examining the configuration to determine why you cannot login (AAA, incorrect local password, etc.).

Updating the Configuration

Here is where this script gets really useful. If you need to update the configuration, but can’t get in because of an erroneous AAA configuration or just want to save time over interactively logging into each device, you can utilize the merge function to merge a configuration that you push to the device. The usage is similar to before, but now we are specifying the configuration file to merge: perl SNMP_Update.pl 192.168.1.1 AAA_SNMP_Changes.txt. Here is the code:

use strict;
use warnings;
use lib “C:/Perl/site/lib”;
use Cisco::CopyConfig ();

# declare variables
my $ipAddress = $ARGV[0];
my $SNMPcommunity = ‘SyComCommunity’;
my $configFile = $ARGV[1];
my $TFTPServer = ‘192.168.52.5’;

# create a new Cisco::CopyConfig object
my $copyConfig = Cisco::CopyConfig->new(
Host => $ipAddress,
Comm => $SNMPcommunity,
);

# merge a configuration file into the running-config via TFTP
print “Now updating running-config on $ipAddress… “;
if($copyConfig->merge($TFTPServer, $configFile)){
print “success.\n”;
}
else{
die $copyConfig->error();
}

# free up memory
$copyConfig = undef;

Here is the AAA_SNMP_Config.txt contents that I pushed to the device:

 

! remove old AAA/TACACS+ configuration
no tacacs-server host 192.168.52.20 key sycomisawesome
no aaa group server tacacs+ nonexistantrsa
no aaa authentication login vtyaccess group nonexistantrsa local enable
no aaa authorization exec vtyaccess group nonexistantrsa local
no aaa authorization commands 15 vtyaccess group nonexistantrsa local
no aaa accounting exec default start-stop group nonexistantrsa
line vty 0 4
no authorization commands 15 vtyaccess
no authorization exec vtyaccess
no login authentication vtyaccess
exit
!
! configure SNMP access for LMS
access-list 50 permit 192.168.52.233
snmp-server community SyCom rw 50
snmp-server community Technologies ro 50
!
! configure new ACS server
ip tacacs source-interface Vlan1
tacacs-server host 192.168.52.138
tacacs-server host 192.168.52.139
tacacs-server key howistheweather
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
end

I ran my TFTP server on my local laptop. The screenshot below illustrates the Solarwinds TFTP logs when merging the configuration changes with the running configuration:

I didn’t mention, but I guess it needs to be said… this method will not work when using a read-only string or if your SNMP community string is protected by an access-list and your machine (that you are running the script from) is not permitted by that access-list. This further emphasizes the need to utilize access-lists on your SNMP community strings and to choose difficult to guess strings. Even take it up a notch and use SNMPv3 instead of v1/v2c, since v3 is much more secure. If you leave your community strings unprotected by an access-list and, even worse, just use ‘public’ and ‘private’, all I have to do is run my script and I can either pull the entire switch configuration to my laptop for analysis or I can completely alter the switch configuration by pushing my own configuration to the switch. Protect yourself. I also didn’t go into detail in the post, but you can easily automate this with a seed CSV of devices and a while loop in the script. Ultimately, LMS does much of what these scripts do, but I often find myself in the position of preparing devices for LMS to manage (i.e. updating AAA and SNMP) and needing something automated up front to prepare them.